Techniques for modifying execution of a computer program based on user input received through a graphical user interface

ABSTRACT

According to at least one aspect, a system for modifying execution of a computer program based on user input received through a graphical user interface (GUI) is provided. The system comprises at least one hardware processor, and at least one non-transitory computer-readable storage medium storing processor-executable instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform a process. The process includes accessing source code of a computer program, generating a GUI including documentation for the computer program and at least one GUI element for receiving user input for modifying execution of the computer program, receiving user input via the at least one GUI element, and modifying execution of the computer program based on the user input provided through the at least one GUI element.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(e) of U.S.Provisional Application Ser. No. 62/384,066, entitled “SYSTEMS ANDMETHODS FOR REAL-TIME PROCESS DOCUMENTATION” filed on Sep. 6, 2016 underAttorney Docket No. S1895.70009US00, which is herein incorporated byreference in its entirety.

FIELD

Aspects of the technology described herein relate to techniques forapplying static source code analysis techniques to a computer program togenerate documentation for the computer program. Some aspects relate totechniques for generating a graphical user interface that permits a userto modify execution of the computer program through manipulation of thedocumentation for the computer program in the graphical user interface.

BACKGROUND

A software engineer typically creates a computer program by developingsource code that comprises a set of instructions in one or moreprogramming languages, such as C, C++, Java, Python, Ruby, C#, andObjective C, and converting the source code into executable code thatmay be executed by a computer system. The software engineer may insertcomments into the source code, such as brief descriptions of the logicimplemented in the source code, to make it easier for other softwareengineers to read and understand the source code. Non-technicalindividuals, however, are typically unable to read the source code orunderstand the implemented logic even with the embedded comments. As aresult, software engineers typically create documentation for thecomputer program that describes the logic implemented in the computerprogram in plain language.

SUMMARY

According to at least one aspect, a system for generating documentationfor a computer program is provided. The system comprises at least onehardware processor; and at least one non-transitory computer-readablestorage medium storing processor executable instructions that, whenexecuted by the at least one hardware processor, cause the at least onehardware processor to perform: accessing source code of a computerprogram comprising a plurality of software modules; analyzing the sourcecode of the computer program at least in part by identifying at leastone relationship between two or more software modules of the pluralityof software modules; obtaining documentation for the computer programusing the at least one relationship between two or more software modulesof the plurality of software modules; and outputting the documentation.

In some embodiments, accessing the source code of the computer programcomprises accessing a plurality of files and wherein at least one filefrom the plurality of files stores at least one software module from theplurality of software modules. In some embodiments, obtainingdocumentation for the computer program comprises: obtaining a pluralityof pieces of documentation associated with a plurality of code portionsof the source code; identifying an execution flow of the computerprogram using the at least one relationship between two or more softwaremodules of the plurality of software modules; and organizing theplurality of pieces of documentation using the identified execution flowof the computer program.

In some embodiments, analyzing the source code comprises generating aplurality of abstract syntax trees (ASTs) comprising an AST for each ofthe two or more software modules of the plurality of software modules.In some embodiments, identifying the at least one relationship betweenthe two or more software modules comprises: identifying at least onerelationship between at least two ASTs in the plurality of ASTs; andgenerating a static information tree (SIT) representative of the atleast one relationship between the at least two ASTs of the plurality ofASTs. In some embodiments, analyzing the source code comprisesgenerating, using the SIT, a control flow graph indicative of anexecution flow of the computer program. In some embodiments, the controlflow graph comprises: a plurality of nodes each associated with a codeportion from a plurality of code portions in the source code; and aplurality of links that connect the plurality of nodes and arerepresentative of one or more execution paths for the computer program.In some embodiments, analyzing the source code comprises generating abusiness flow graph from the control flow graph at least in part byremoving at least some nodes from the plurality of nodes in the controlflow graph. In some embodiments, removing the at least some nodes fromthe plurality of nodes in the control flow graph comprises removing atleast one node from the plurality of nodes that is associated with acode portion from the plurality of code portions that does not use atleast one predetermined variable.

In some embodiments, the source code comprises at least one comment andat least one marker associated with the comment that indicates the atleast one comment is to be included in the documentation. In someembodiments, obtaining the documentation comprises: identifying the atleast one marker in the source code; extracting the at least one commentassociated with the at least one marker in the source code; and addingthe at least one comment to the documentation.

In some embodiments, obtaining documentation comprises converting atleast a portion of the source code into natural language text. In someembodiments, outputting the documentation comprises at least one memberselected from the group consisting of: printing the documentation,saving the documentation, generating a webpage comprising thedocumentation, and generating a document comprising the documentation.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, a method for generating documentationfor a computer program is provided. The method comprises: using at leastone hardware processor to perform: accessing source code of a computerprogram comprising a plurality of software modules; analyzing the sourcecode of the computer program at least in part by identifying at leastone relationship between two or more software modules of the pluralityof software modules; obtaining documentation for the computer programusing the at least one relationship between two or more software modulesof the plurality of software modules; and outputting the documentation.

In some embodiments, accessing the source code of the computer programcomprises accessing a plurality of files and wherein at least one filefrom the plurality of files stores at least one software module from theplurality of software modules. In some embodiments, obtainingdocumentation for the computer program comprises: obtaining a pluralityof pieces of documentation associated with a plurality of code portionsof the source code; identifying an execution flow of the computerprogram using the at least one relationship between two or more softwaremodules of the plurality of software modules; and organizing theplurality of pieces of documentation using the identified execution flowof the computer program.

In some embodiments, analyzing the source code comprises generating aplurality of abstract syntax trees (ASTs) comprising an AST for each ofthe two or more software modules of the plurality of software modules.In some embodiments, identifying the at least one relationship betweenthe two or more software modules comprises: identifying at least onerelationship between at least two ASTs in the plurality of ASTs; andgenerating a static information tree (SIT) representative of the atleast one relationship between the at least two ASTs of the plurality ofASTs. In some embodiments, analyzing the source code comprisesgenerating, using the SIT, a control flow graph indicative of anexecution flow of the computer program. In some embodiments, the controlflow graph comprises: a plurality of nodes each associated with a codeportion from a plurality of code portions in the source code; and aplurality of links that connect the plurality of nodes and arerepresentative of one or more execution paths for the computer program.In some embodiments, analyzing the source code comprises generating abusiness flow graph from the control flow graph at least in part byremoving at least some nodes from the plurality of nodes in the controlflow graph. In some embodiments, removing the at least some nodes fromthe plurality of nodes in the control flow graph comprises removing atleast one node from the plurality of nodes that is associated with acode portion from the plurality of code portions that does not use atleast one predetermined variable.

In some embodiments, the source code comprises at least one comment andat least one marker associated with the comment that indicates the atleast one comment is to be included in the documentation. In someembodiments, obtaining the documentation comprises: identifying the atleast one marker in the source code; extracting the at least one commentassociated with the at least one marker in the source code; and addingthe at least one comment to the documentation.

In some embodiments, obtaining documentation comprises converting atleast a portion of the source code into natural language text. In someembodiments, outputting the documentation comprises at least one memberselected from the group consisting of: printing the documentation,saving the documentation, generating a webpage comprising thedocumentation, and generating a document comprising the documentation.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, at least one non-transitorycomputer-readable storage medium is provided. The at least onenon-transitory computer-readable storage medium storesprocessor-executable instructions that, when executed by at least onehardware processor, cause the at least one hardware processor toperform: accessing source code of a computer program comprising aplurality of software modules; analyzing the source code of the computerprogram at least in part by identifying at least one relationshipbetween two or more software modules of the plurality of softwaremodules; obtaining documentation for the computer program using the atleast one relationship between two or more software modules of theplurality of software modules; and outputting the documentation.

According to at least one aspect, a system for generating documentationfor a computer program is provided. The system comprises at least onehardware processor; and at least one non-transitory computer-readablestorage medium storing processor executable instructions that, whenexecuted by the at least one hardware processor, cause the at least onehardware processor to perform: accessing source code of a computerprogram; analyzing the source code of the computer program at least inpart by identifying an execution flow of the computer program; obtainingdocumentation for the computer program using the identified executionflow; and outputting the documentation.

In some embodiments, obtaining documentation for the computer programcomprises: obtaining a plurality of pieces of documentation associatedwith a plurality of code portions of the source code; and organizing theplurality of pieces of documentation using the identified execution flowof the computer program.

According to at least one aspect, a system is provided. The systemcomprises at least one hardware processor; and at least onenon-transitory computer-readable storage medium storing processorexecutable instructions that, when executed by the at least one hardwareprocessor, cause the at least one hardware processor to perform:accessing source code of a computer program; generating informationindicative of execution flow of the computer program at least in part byanalyzing the source code; executing the computer program; obtaininginformation gathered during execution of the computer program; andgenerating a graphical user interface (GUI) using the informationindicative of the execution flow and the information gathered duringexecution of the computer program, the generating comprising generatinga first view comprising: a visualization of the execution flow of thecomputer program; and a plurality of GUI elements, each of the pluralityof GUI elements associated with a corresponding code portion in thesource code of the computer program.

In some embodiments, obtaining the information gathered during executionof the computer program comprises obtaining at least one of: an image, avideo, or a text file generated during execution of the computerprogram. In some embodiments, generating the first view comprisesmodifying a characteristic of at least one GUI element of the pluralityof GUI elements based on the information gathered during execution ofthe computer program. In some embodiments, the characteristic of the atleast one GUI element comprises at least one member selected from thegroup consisting of: a size, a shape, and a color.

In some embodiments, the first view comprises a link between at leasttwo GUI elements of the plurality of GUI elements representative of arelationship between the corresponding code portions associated with theat least two GUI elements. In some embodiments, generating the firstview comprises modifying a characteristic of the link based on theinformation gathered during execution of the computer program. In someembodiments, the characteristic of the link comprises at least onemember selected from the group consisting of: a size, a shape, and acolor.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: transitioning the GUI from thefirst view to a second view upon selection of at least one GUI elementof the plurality of GUI elements. In some embodiments, the second viewcomprises documentation for the corresponding code portion associatedwith the selected at least one GUI element. In some embodiments, thedocumentation comprises natural language text.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, a method is provided. The methodcomprises using at least one hardware processor to perform: accessingsource code of a computer program; generating information indicative ofexecution flow of the computer program at least in part by analyzing thesource code; executing the computer program; obtaining informationgathered during execution of the computer program; and generating agraphical user interface (GUI) using the information indicative of theexecution flow and the information gathered during execution of thecomputer program, the generating comprising generating a first viewcomprising: a visualization of the execution flow of the computerprogram; and a plurality of GUI elements, each of the plurality of GUIelements associated with a corresponding code portion in the source codeof the computer program.

In some embodiments, obtaining the information gathered during executionof the computer program comprises obtaining at least one of: an image, avideo, or a text file generated during execution of the computerprogram. In some embodiments, generating the first view comprisesmodifying a characteristic of at least one GUI element of the pluralityof GUI elements based on the information gathered during execution ofthe computer program. In some embodiments, the characteristic of the atleast one GUI element comprises at least one member selected from thegroup consisting of: a size, a shape, and a color.

In some embodiments, the first view comprises a link between at leasttwo GUI elements of the plurality of GUI elements representative of arelationship between the corresponding code portions associated with theat least two GUI elements. In some embodiments, generating the firstview comprises modifying a characteristic of the link based on theinformation gathered during execution of the computer program. In someembodiments, the characteristic of the link comprises at least onemember selected from the group consisting of: a size, a shape, and acolor.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: transitioning the GUI from thefirst view to a second view upon selection of at least one GUI elementof the plurality of GUI elements. In some embodiments, the second viewcomprises documentation for the corresponding code portion associatedwith the selected at least one GUI element. In some embodiments, thedocumentation comprises natural language text.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, at least one non-transitorycomputer-readable storage medium. The at least one non-transitorycomputer-readable storage medium stores processor-executableinstructions that, when executed by at least one hardware processor,cause the at least one hardware processor to perform: accessing sourcecode of a computer program; generating information indicative ofexecution flow of the computer program at least in part by analyzing thesource code; executing the computer program; obtaining informationgathered during execution of the computer program; and generating agraphical user interface (GUI) using the information indicative of theexecution flow and the information gathered during execution of thecomputer program, the generating comprising generating a first viewcomprising: a visualization of the execution flow of the computerprogram; and a plurality of GUI elements, each of the plurality of GUIelements associated with a corresponding code portion in the source codeof the computer program.

According to at least one aspect, a system is provided. The systemcomprises at least one hardware processor; and at least onenon-transitory computer-readable storage medium storingprocessor-executable instructions that, when executed by the at leastone hardware processor, cause the at least one hardware processor toperform: accessing source code of a computer program; generating agraphical user interface (GUI) including: documentation for the computerprogram; and at least one GUI element for receiving user input formodifying execution of the computer program; receiving user input viathe at least one GUI element; and modifying execution of the computerprogram based on the user input provided through the at least one GUIelement.

In some embodiments, modifying execution of the computer programcomprises setting at least one value of at least one parameter of thecomputer program based on the user input provided through the at leastone GUI element. In some embodiments, modifying execution of thecomputer program comprises identifying, based on the user input providedthrough the at least one GUI element, one or more portions of the sourcecode to not execute during execution of the computer program. In someembodiments, the processor-executable instructions further cause the atleast one processor to perform: modifying presentation of thedocumentation in the GUI based on the user input provided through the atleast one GUI element. In some embodiments, modifying presentation ofthe documentation in the GUI comprises visually highlighting a portionof the documentation affected by the modification.

In some embodiments, modifying execution of the computer programcomprises generating modified source code for the computer program usingthe source code and the user input. In some embodiments, modifyingexecution of the computer program comprises generating a modifiedexecutable code based on the modified source code and executing themodified executable code.

In some embodiments, the computer program is configured to read at leastone value from a file during execution and wherein modifying executionof the computer program comprises changing the at least one value in thefile. In some embodiments, the at least one GUI element comprises atleast one element selected from the group consisting of: a drop-downlist, a radio button, a toggle button, a checkbox, a text field, and aslider.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: generating information indicativeof execution flow of the computer program at least in part by analyzingthe source code; and obtaining the documentation using the informationindicative of execution flow of the computer program. In someembodiments, generating the GUI comprises: generating a visualization ofthe execution flow of the computer program that comprises a plurality ofGUI elements each associated with a corresponding code portion in thesource code of the computer program.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: generating initial documentationfor the computer program at least in part by analyzing the source codeof the computer program; obtaining information gathered during executionof the computer program; and updating the initial documentation by usingthe information gathered during execution of the computer program toobtain the documentation to include in the GUI. In some embodiments,analyzing the source code of the computer program comprises generatingat least one abstract syntax tree (AST) for the source code. In someembodiments, the source code of the computer program comprises aplurality of software modules, and wherein generating the at least oneAST for the source code comprises generating an AST for each of theplurality of software modules.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, a method is provided. The methodcomprises using at least one hardware processor to perform: accessingsource code of a computer program; generating a graphical user interface(GUI) including: documentation for the computer program; and at leastone GUI element for receiving user input for modifying execution of thecomputer program; receiving user input via the at least one GUI element;and modifying execution of the computer program based on the user inputprovided through the at least one GUI element.

In some embodiments, modifying execution of the computer programcomprises setting at least one value of at least one parameter of thecomputer program based on the user input provided through the at leastone GUI element. In some embodiments, modifying execution of thecomputer program comprises identifying, based on the user input providedthrough the at least one GUI element, one or more portions of the sourcecode to not execute during execution of the computer program. In someembodiments, the processor-executable instructions further cause the atleast one processor to perform: modifying presentation of thedocumentation in the GUI based on the user input provided through the atleast one GUI element. In some embodiments, modifying presentation ofthe documentation in the GUI comprises visually highlighting a portionof the documentation affected by the modification.

In some embodiments, modifying execution of the computer programcomprises generating modified source code for the computer program usingthe source code and the user input. In some embodiments, modifyingexecution of the computer program comprises generating a modifiedexecutable code based on the modified source code and executing themodified executable code.

In some embodiments, the computer program is configured to read at leastone value from a file during execution and wherein modifying executionof the computer program comprises changing the at least one value in thefile. In some embodiments, the at least one GUI element comprises atleast one element selected from the group consisting of: a drop-downlist, a radio button, a toggle button, a checkbox, a text field, and aslider.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: generating information indicativeof execution flow of the computer program at least in part by analyzingthe source code; and obtaining the documentation using the informationindicative of execution flow of the computer program. In someembodiments, generating the GUI comprises: generating a visualization ofthe execution flow of the computer program that comprises a plurality ofGUI elements each associated with a corresponding code portion in thesource code of the computer program.

In some embodiments, the processor-executable instructions further causethe at least one processor to perform: generating initial documentationfor the computer program at least in part by analyzing the source codeof the computer program; obtaining information gathered during executionof the computer program; and updating the initial documentation by usingthe information gathered during execution of the computer program toobtain the documentation to include in the GUI. In some embodiments,analyzing the source code of the computer program comprises generatingat least one abstract syntax tree (AST) for the source code. In someembodiments, the source code of the computer program comprises aplurality of software modules, and wherein generating the at least oneAST for the source code comprises generating an AST for each of theplurality of software modules.

In some embodiments, the computer program is configured to controlanother computer program to perform a task. In some embodiments, thecomputer program is configured to control the other computer program toperform the task at least in part by controlling a graphical userinterface (GUI) of the other computer program to perform an action infurtherance of the task.

According to at least one aspect, at least one non-transitorycomputer-readable storage medium is provided. The at least onenon-transitory computer-readable storage medium storesprocessor-executable instructions that, when executed by at least onehardware processor, cause the at least one hardware processor toperform: accessing source code of a computer program; generating agraphical user interface (GUI) including: documentation for the computerprogram; and at least one GUI element for receiving user input formodifying execution of the computer program; receiving user input viathe at least one GUI element; and modifying execution of the computerprogram based on the user input provided through the at least one GUIelement.

BRIEF DESCRIPTION OF DRAWINGS

Various aspects and embodiments will be described with reference to thefollowing figures. It should be appreciated that the figures are notnecessarily drawn to scale. Items appearing in multiple figures areindicated by the same reference number in all the figures in which theyappear.

FIG. 1 is a diagram of an example system for generating documentationfor a computer program, according to some embodiments of the technologydescribed herein;

FIG. 2 is a diagram of an example process of generating documentationfrom source code, according to some embodiments of the technologydescribed herein;

FIG. 3 is a diagram of an example abstract syntax tree (AST), accordingto some embodiments of the technology described herein;

FIG. 4 is a diagram of an example static information tree (SIT),according to some embodiments of the technology described herein;

FIG. 5 is a diagram of an example control flow graph, according to someembodiments of the technology described herein;

FIG. 6 is a flowchart of an example process for generating documentationfor a computer program, according to some embodiments of the technologydescribed herein;

FIG. 7 is a flowchart of an example process for generating a graphicaluser interface (GUI) to display documentation for a computer program,according to some embodiments of the technology described herein;

FIG. 8 is a flowchart of an example process for modifying execution of acomputer program based on user input received through a GUI, accordingto some embodiments of the technology described herein;

FIGS. 9A-9B are diagrams of an example user interface, according to someembodiments of the technology described herein;

FIGS. 10A-10C are diagrams of another example user interface, accordingto some embodiments of the technology described herein; and

FIG. 11 is a block diagram of an example computer system, according tosome embodiments of the technology described herein.

DETAILED DESCRIPTION

As discussed above, software engineers typically create and maintaindocumentation for a computer program to assist non-technical individualsin understanding the logic implemented in the computer program.Conventional document creation computer applications, such as DOXYGENand JAVADOC, attempt to ease the burden of creating documentation forApplication Programming Interfaces (APIs) of a computer program. Theseconventional applications extract the documentation directly fromcomments embedded in the source code of the computer program withoutanalyzing the source code itself. The resulting documentation contains alisting of functions that may be accessed through the API along theextracted comments from the source code associated with these functions.

The inventors have recognized and appreciated that conventional documentgeneration applications only create documentation for a limited portionof a computer program, i.e., the API. As a result, these conventionaldocument generation applications fail to extract information regardingthe execution flow of the computer program such as the logic implementedto create functions. For example, documentation created by suchconventional documentation generation applications does not describe theorder in which certain functions are called and/or which conditions (ifany) must be met for functions to be executed. As a result, thedocumentation created by these applications is not in plain languagesuitable for non-technical individuals because API documentation isintended for consumption by software engineers developing computerprograms that interact with the API.

Accordingly, aspects of the present disclosure relate to new techniquesfor automated generation of documentation for computer programs. In someembodiments, the documentation may be generated using, for example, thesource code for the computer program. In some embodiments, the sourcecode may be analyzed to determine an execution flow of the computerprogram. The execution flow of the computer program may be representedas, for example, a control flow graph that comprises a plurality ofnodes each associated with a code portion of the source code. Thesenodes may be connected by links that are indicative of the order ofexecution of the code portions. The control flow graph may be employedto, for example, create an index for the documentation that is organizedin a logical manner (e.g., organized by order of execution). The indexmay comprise an entry for at least some of the code portions in thecontrol flow graph. Documentation may then be obtained (or otherwisegenerated) for one or more entries in the index by analyzing the sourcecode (e.g., the respective code portion associated with the entry). Forexample, the documentation may be extracted from comments in a codeportion and/or generated by converting the code portion to naturallanguage text (e.g., text that employs commonly used words in simplesentences) that a non-technical individual is able to understand. Thegenerated documentation for each code portion in combination with theindex that logically organizes the code portions provides documentationfor the entire computer program that is easy to navigate and understandfor non-technical individuals.

The natural language text in the documentation may be supplemented byother information, such as information gathered during execution of thecomputer program. This supplemental information may further assistnon-technical individuals to understand how the computer programfunctions. For example, screenshots of a graphical user interface (GUI)of the computer program during execution of one or more code portionsmay be incorporated into the documentation. Additionally (oralternatively), information indicative of how many times one or morecode portion is executed may be incorporated into the documentation.

The inventors have further appreciated that non-technical individualsmay want to modify how the computer program executes. For example, asoftware engineer may deliver a computer program to a client and theclient may want to make small changes to the computer program.Conventionally, the client would need to communicate the desired changesto the software engineer who, in turn, creates a modified version of thecomputer program. The time required to perform this revision process maybe substantial and increase the total cost of developing the computerprogram paid by the client.

Accordingly, aspects of the present disclosure relate to new techniquesfor permitting non-technical individuals to make modifications to acomputer program without directly interacting with the source code. Insome embodiments, a user (e.g., a non-technical individual) maymanipulate the documentation for a computer program through a GUI tomake changes to the computer program. For example, the documentation forthe computer program may comprise one or more configurable fields thatthe user may manipulate to modify the computer program. A change to avalue in configurable field may automatically trigger a change to thecomputer program. The computer program may be modified in any of avariety of ways. For example, modified source code may be generated thatincludes the change and converted into a modified executable code thatmay be executed in place of the original executable code for thecomputer program. In another example, the computer program may beconfigured to read one or more values from a file during execution. Inthis example, the values in the file may be adjusted based on the userinput to change the values read-in by the computer program duringexecution.

In some embodiments, the computer program for which the documentation isbeing generated for is a software robot computer program (hereinafter,“software robot”). Software robots may be, for example, computerprograms configured to programmatically control one or more othercomputer programs (e.g., one or more application programs and/or one ormore operating systems) to perform one or more tasks at least in partvia the GUIs and/or APIs of the other computer program(s). A task maybe, for example, a sequence of one or more actions (e.g., buttons clicksand/or keystrokes) that culminates in an objective being completed suchas resetting a password or creating a document. A software robot mayperform one or more tasks to complete a process. Some aspects ofsoftware robots are described in U.S. Patent Publication No.2016-0259651, titled “SOFTWARE ROBOTS FOR PROGRAMMATICALLY CONTROLLINGCOMPUTER PROGRAMS TO PERFORM TASKS,” published on Sep. 8, 2016, which isincorporated herein by reference in its entirety.

Software robots may be, for example, employed by companies to automateone or more processes with business relevance. Examples of suchprocesses include: processing purchase orders (PO's) and processinginsurance claims. Thereby, companies may reduce the time employees spendperforming mundane processes by deploying software robots. Thesecompanies may, however, wish to still have some level of control overtheir processes. A manager, for example, may be accustomed to easilybeing able to change how a process is performed by simply asking anemployee to perform the process differently. In cases where a softwarerobot is performing the process, the manager would typically need torequest software engineers to modify the underlying source code for thesoftware robot and wait for the new software robot to be deployed.Accordingly, the techniques described herein to automatically generatedocumentation to display via a GUI and/or permit a user (e.g., anon-technical person) to make changes to the documentation in the GUImay be employed to significantly lower the barriers for a company tomodify a process being performed by a software robot. For example, amanager may easily manipulate documentation for a software robot in aGUI to change how the software robot performs a process. Thereby, themanager can obtain the benefits of deploying software robots to automatea business process while still being able to easily make changes to theprocess as the needs of the company change.

Example Implementation

Some aspects of the present disclosure relate to a system forautomatically generating documentation for a computer program. Such asystem may be referred to herein as a “Live Documentation” system or a“LiveDoc” system. The documentation generated in accordance with thetechniques described herein may be referred to as “Live Documentation”or “LiveDoc.” The system may comprise, for example, at least onehardware processor that coupled to at least one non-transitorycomputer-readable storage medium storing processor executableinstructions that, when executed by the at least one hardware processor,cause the at least one hardware processor to perform various functionsto automatically generate documentation. The instructions may cause thehardware processor to access source code of a computer program. Thesource code may be, for example, a set of instructions in one or moreprogramming languages, such as C, C++, Java, Python, Ruby, C#, andObjective C. These instructions may be sub-divided into multiplesoftware modules. These software modules may be stored separately intheir own files or together in one file.

The instructions may further cause the hardware processor to analyze thesource code of the computer program. The source code may be analyzed by,for example, identifying relationships between the software modules inthe source code. These relationships may be indicative of, for example,functions in a first software module that are defined (or otherwisecreated) in a second software module. The relationships between softwaremodules may be identified by, for example, creating an abstract syntaxtree (AST) for each of the software modules. These ASTs may comprise aplurality of nodes that represent a construct (e.g., a software module,a function call, a function definition, and/or an assignment statement)in the code of a software module that are interconnected by links thatillustrate the relationships between constructs within the AST. Once theASTs have been generated, relationships between ASTs may be generated byidentifying relationships between constructs in different ASTs. Forexample, a first AST in a set of ASTs may be parsed to identify a firstconstruct in the first AST that references a second construct in anotherAST (e.g., a function call for a function that is defined in anothersoftware module). In this example, one or more other ASTs in the set ofASTs may be searched until the second construct is located (e.g., thedefinition for the function is located). Once the second construct hasbeen located, the relationship between the first and second constructsmay be stored. These relationships between the ASTs may be embodied in,for example, a static information tree (SIT).

The instructions may further cause the hardware processor to obtaindocumentation for the computer program using the identifiedrelationships between software modules, such as the SIT. In someembodiments, the documentation may be obtained at least in part bygenerating a control flow graph for the computer program that isindicative of the execution flow of the computer program using thegenerated SIT. The control flow graph may comprise, for example, aplurality of nodes each associated with a code portion from the sourcecode and a plurality of links that illustrate relationships between thecode portions. The code portions may be, for example, one or more linesof code from one or more software modules in the source code. The linksmay be representative of an execution order of the code portions. TheSIT may be employed to, for example, identify the location of functiondefinitions for function calls in a given code portion. For example, acode portion may comprise a function call for a function that is locatedin another portion of the source code. In this example, the SIT may beemployed to identify the location of the function definition andassociate the function definition with the function call in the codeportion.

The control flow graph may serve as, for example, an index for thedocumentation where each code portion is an entry in the index and theentries are ordered based on execution order. Thereby, natural languagetext may be associated with each of these entries (and their associatedcode portions) to form documentation that is easy to understand andsearch for non-technical individuals. The documentation for each entrymay be, for example, obtained directly from comments embedded in thecode portions and/or generated by converting the code portions tonatural language text.

It should be appreciated that not all of the nodes in the control flowgraph may be employed to create the index for the documentation. Forexample, a simplified version of the control flow graph referred toherein as a “business flow graph” may be used instead. Thereby, thedocumentation may be simplified to make it easier to understand fornon-technical individuals. The business flow graph may be created by,for example, removing nodes from the control flow graph that arespecific to the implementation of the process in the source code. Thesenodes (and their associated code portions) may be separated from theremaining nodes (and their associated code portions) in any of a varietyof ways. For example, these nodes may be removed by removing one or moreof the nodes in the control flow graph that are associated with codeportions which do not involve one or more predetermined variables (e.g.,important variables).

The instructions may further cause the hardware processor to output thedocumentation. The documentation may be output in any of a variety offormats. For example, the documentation may be output as a text fileand/or a webpage. Alternatively (or additionally), the documentation maybe output to a user via a GUI.

Some aspects of the present disclosure relate to a system for generatinga GUI to display documentation for a computer program. The documentationmay comprise, for example, information gathered during execution of thecomputer program. Thereby, a user (e.g., a non-technical person) maygain a better understanding of how the computer program is executed. Thesystem may comprise, for example, at least one hardware processor thatcoupled to at least one non-transitory computer-readable storage mediumstoring processor executable instructions that, when executed by the atleast one hardware processor, cause the at least one hardware processorto perform various functions to generate a GUI for displayingdocumentation for a computer program. The instructions may cause thehardware processor to access source code of a computer program. Thesource code (and/or any associated executable code) may compriseinstructions that cause the computer program to capture informationduring execution and store the information at a pre-determined location.Thereby, the computer program may make the information gathered duringexecution readily available. For example, the computer program maycapture screenshots of a user interface of the computer program duringexecution and store the screenshots in a file. In another example wherethe computer program is a software robot, the software robot may capturescreenshots of a user interface of another computer program beingcontrolled by the software robot during execution and store thescreenshot in a file. Alternatively (or additionally), the computerprogram may count a number of times code portions in the source code areexecuted and store the value in a file.

The instructions may further cause the hardware processor to generateinformation indicative of an execution flow of the computer program,such as a control flow graph and/or a business flow graph, at least inpart by analyzing the source code. The information indicative of anexecution flow of the computer program may be generated in any of avariety of ways using, for example, any of the techniques describedherein. For example, ASTs may be generated for one or more softwaremodules in the source code and relationships between the ASTs may beidentified to generate an SIT. In this example, the SIT (and/or theASTs) may be employed to generate the information indicative of theexecution flow of the computer program.

The instructions may further cause the hardware processor to execute thecomputer program. The computer program may be executed by, for example,running executable code associated with the computer program. Asdiscussed above, computer program may be configured to captureinformation during execution and store the captured information at apre-determined location. The instructions may further cause the hardwareprocessor to obtain this information gathered during execution of thecomputer program. For example, one or more files at a pre-determinedstorage location where the computer program stores the capturedinformation may be read.

The instructions may further cause the hardware processor to generate aGUI using the information indicative of the execution flow and theinformation gathered during execution of the computer program. Forexample, the GUI may comprise a first view where a visualization of theexecution flow of the computer program is presented. This visualizationmay be, for example, a rendering of a generated control flow graphand/or business flow graph. The visualization may comprise a pluralityof GUI elements (e.g., nodes) that are each associated with acorresponding code portion in the source code. These nodes may beorganized based on an order of execution of the code portions associatedwith the nodes. The GUI may transition from the first view to a secondview upon selection of one of the nodes. The second view may comprise,for example, documentation for the code portion associated with theselected node. The documentation may comprise, for example, informationgathered during execution of the computer program, such as a screenshot,and/or natural language text describing the logic implemented in thecode portion.

Some aspects of the present disclosure relate to a system for modifyingexecution of a computer program based on user input received through aGUI. The GUI may comprise, for example, documentation for a computerprogram with a GUI element (e.g., a configurable field) that may bemanipulated by a user (e.g., a non-technical individual). The system maymodify execution of the computer program based on user input in a GUIelement. The system may comprise, for example, at least one hardwareprocessor that coupled to at least one non-transitory computer-readablestorage medium storing processor executable instructions that, whenexecuted by the at least one hardware processor, cause the at least onehardware processor to perform various functions to modify execution of acomputer program based on user input received through a GUI. Theinstructions may cause the hardware processor to access the source codeof a computer program and generate a GUI including documentation for thecomputer program. The documentation in the GUI may be generated manually(e.g., generated by a software engineer) and/or generated automaticallybased on the source code using any of a variety of techniques includingany of the techniques described herein. The GUI may further include atleast one GUI element for receiving user input to change execution ofthe computer program. The at least one GUI element may comprise, forexample, a drop-down list, a radio button, a toggle button, a checkbox,a text field, and/or a slider.

The instructions may further cause the hardware processor to receiveuser input via the at least one GUI element. The user input may be, forexample, manipulation of the GUI element by the user. The instructionsmay further cause the hardware processor to modify execution of thecomputer program based on the user input. The execution of the computerprogram may be modified in any of a variety of ways. For example, thesource code may be modified based on the user input and converted intomodified executable code (e.g., using a compiler and/or a linker). Themodified executable code may then be executed in place of the originalexecutable code. In another example, the executable code may read one ormore values from a file at a predetermined location, such as values forone or more variables in computer program. In this example, theexecution of the code may be modified by changing one or more values inthe file that is read-in by the computer program.

It should be appreciated that the embodiments described herein may beimplemented in any of numerous ways. Examples of specificimplementations are provided below for illustrative purposes only. Itshould be appreciated that these embodiments and thefeatures/capabilities provided may be used individually, all together,or in any combination of two or more, as aspects of the technologydescribed herein are not limited in this respect.

Example LiveDoc System

FIG. 1 shows an example LiveDoc system 100 that is configured togenerate software documentation for a computer program, such as asoftware robot. The LiveDoc system 100 accesses source code 104 and/orexecutable code 106 of a computer program to generate softwaredocumentation that may be presented to a user 120 via a GUI 122. TheLiveDoc system 100 comprises a natural language conversion component 114that generates natural language text that may be incorporated into thesoftware documentation shown in the GUI 122 using the source code 104. Astorage component 118 in the LiveDoc system 100 receives informationfrom the executable code 106 at runtime, such as screenshots, video, anddocuments, that may be incorporated into the software documentation inthe GUI 122. A configuration channel 116 in the LiveDoc system 100 isconfigured to make changes to the source code and/or the executable codebased on manipulations of the GUI 122 by the user 120. Thereby, the user120 may make changes to the source code by manipulating the GUI 122.

The source code 104 of a computer program may be, for example, acollection of computer instructions written in a programming language.The collection of computer instructions may be organized into one ormore software modules. Each of the software modules may be a componentof a computer program that comprises one or more software routines. Thesoftware modules may be stored separately in different computer filesand/or stored together in a single computer file.

In some embodiments, the source code 104 may comprise comments. Thesecomments may be, for example, annotations in the source code 104 thatmay be inserted by a software developer to make the source code easierto read and/or understand. The source code 104 may comprise multipletypes of comments. For example, the source code 104 may comprise regularcomments that are intended to only be read by other software developerswho directly read the source code 104 and special comments that areintended to be incorporated into the software documentation generated bythe LiveDoc system 100. Regular comments may be delineated from specialcomments by a marker, such as a unique sequence of characters, insertedinto the source code 104. Thereby, the LiveDoc system 100 may easilyextract the special comments from the source code for inclusion in thedocumentation.

The natural language conversion component 114 may be configured togenerate documentation using the source code 104. The generateddocumentation may be, for example, displayed via the GUI 122. Thenatural language conversion component 114 may generate the documentationusing the source code 104 in any of a variety of ways. In someembodiments, the natural language conversion component 114 is configuredto identify an execution flow of the source code 104 and organizedocumentation using the identified execution flow of the source code104. In these embodiments, the documentation itself may be extractedfrom the source code 104 and/or generated by converting one or morelines of code in the source code to natural language text. For example,the natural language conversion component 114 may extract specialcomments embedded in the source code 104 to include in thedocumentation. In another example, the natural language conversioncomponent 114 may convert one or more lines of code in the source code104 to natural language text by filling in variable names and/or valuesin template sentences for a set of predetermined constructs in thesource code 104, such as software modules, function calls, functiondefinitions, and/or assignment statements.

FIG. 2 shows an example process 200 that may be employed by the naturallanguage conversion component 114 to generate documentation 218 based onsource code 202. As shown, the source code 202 is sub-divided into aplurality of software modules 204A-204C with one or more softwareroutines. The software modules 204A-204C may be stored together in asingle file or stored separately across multiple files. The softwaremodules 204A-204C may be parsed using, for example, a static source codeparser (e.g., a recursive parser) to generate an AST set 206 comprisingan AST for each of the software modules 204A-204C shown as ASTs208A-208C. Any of a variety of static source code parsers may beemployed such as those available through open source libraries (e.g.,JAVAPARSER). The ASTs 208A-208C may be, for example, a treerepresentation of the abstract syntactic structure of the instructionscontained in the software modules 204A-204C. The generated ASTs208A-208C, however, may not contain information indicative of how theASTs 208A-208C (and their corresponding software modules 204A-204C) arelinked. For example, AST 208A (and thereby software module 204A) maycomprise a function call to a function that is defined in a separateAST, such as AST 208B (and thereby software module 204B).

Accordingly, in some embodiments, the ASTs 208A-208C may be linkedtogether to represent the relationships between the ASTs 208A-208C. Therelationships between the ASTs 208A-208C may be identified in any of avariety of ways. In some embodiments, the SIT 210 may be formed by, forexample, parsing of all the ASTs in the AST set 206. For example, theAST 208A may be analyzed to identify one or more function calls in theAST 208A that are not defined within the AST 208A. For each of thesefunction calls, the other ASTs (e.g., ASTs 208B and 208C) may besearched to location the corresponding definitions. These relationshipsmay be embodied in SIT 210.

The SIT 210 may comprise, for example, a plurality of nodes eachrepresentative of a construct in the source code 202 (such as a module,class, function and/or variable). Relationships between these nodes,such as parent-child relationships, may be represented by links betweennodes. For example, a variable may be represented as a first node thatis linked as a child to a second node associated with the softwaremodule in which the variable is defined. These relationships may beassociated with nodes in the form of attributes. For example, anattribute for a given node may comprise a pointer to one or more parentnodes. In some embodiments, some types of nodes (such as nodes forfunctions or variables) may have different attributes than other typesof nodes (such as nodes for classes). For example, the nodes forvariables may comprise an attribute that is representative of the classof the variable. In another example, the nodes for functions maycomprise an attribute that is representative of the class of the objectthat the function returns.

The SIT 210 may be employed alone or in combination with one or moreASTs in the AST set 206 to create a control flow graph 212 that isindicative of an execution flow of the source code 202. The control flowgraph 212 may comprise a plurality of nodes that are each associatedwith a code portion of the source code 202 and a plurality of links(sometimes referred to as “edges”) that connect the nodes. The codeportions may be, for example, one or more lines of code from one or moresoftware modules (e.g., software modules 204A-204C) in the source code202. The links may be representative of an execution order of the codeportions. The control flow graph 212 may be generated using any of avariety of techniques. In some embodiments, the control flow graph 212may be generated by parsing the source code 202 using the SIT 210(and/or ASTs 208A-208C) as a guide to indicate where constructs in thesource code 202 are defined. For example, a code portion in the sourcecode 202 may be encountered that employs a function call that is definedin another portion of the source code 202. In this example, the SIT 210may be employed to locate the function definition and associate thefunction definition with the function call in the code portion.

As discussed above, the control flow graph 212 may comprise a pluralityof nodes associated with a plurality of code portions in the source code202. Some of these nodes may be for code portions that are related tothe particular implementation of the process in the source code 202instead of the high-level process. For example, the source code 202 maybe for a software robot that is configured to process invoices forpurchased goods by performing the following high-level process: (1)identifying the purchased goods listed on the invoice; (2) determiningwhether the purchased goods were received; and (3) paying the invoice ifthe purchased goods were received. A control flow graph for such asoftware robot may comprise nodes that directly relate to thishigh-level process (e.g., a node for a code portion that determineswhether the goods received match the goods listed on the invoice) withnodes that are specific to the implementation (e.g., a node for a codeportion that is a counter in a for-loop).

Accordingly, in some embodiments, the nodes for code portions related tothe particular implementation of the process in the source code 202 maybe separated from the nodes for code portions related to the high-levelprocess. The nodes for code portions related to the high-level processmay be identified using a business rule set 214. Business rule set 214may comprise, for example, a plurality of rules that classify nodes aseither implementation related or high-level process related. Forexample, a rule may specify that any node whose corresponding codeportion comprises an important variable may be high-level processrelated. Thereby, the nodes related to the implementation may be removedfrom the control flow graph 212 to form a simplified control flow graphshown as business flow graph 216. For illustration, a software robotthat is configured to process invoices may have an “invoice amountvariable” identified as an important variable. Thereby, all of the nodesthat employ the “invoice amount variable” may be deemed important nodeswhile other nodes (such as nodes that increment a counter) may be deemedunimportant and, thereby, removed.

The business flow graph 216 (and/or the control flow graph 212) may beemployed to generate the documentation 218. For example, the businessflow graph 216 (and/or the control flow graph 212) may be employed tocreate an index for the documentation 218. For example, one or morenodes in the business flow graph 216 (and/or the control flow graph 212)may become entries in the index. Thereby, the documentation 218 may belogically organized (e.g., by order of execution) to assistnon-technical users to navigate the documentation. The documentation fora given node may comprise, for example, natural language textdescriptive of the logic implemented in the code portion associated withthe node.

In some embodiments, the documentation for a given node is directlyextracted from the code portion. In these embodiments, the code portionmay comprise special comments that are added to the code portion by, forexample, a software engineer. These special comments may be marked inthe code portion using a unique marker and/or flag to distinguish thesespecial comments from regular comments not intended to be added to thedocumentation. Thereby, the special comments in a code portion may beeasily extracted and incorporated into the documentation.

In some embodiments, the documentation for a given node is automaticallygenerated through analysis of the source code (e.g., the code portion).For example, one or more lines of source code in a given code portionmay converted to natural language text. The conversion to naturallanguage text may be performed in any of a variety of ways. In someembodiments, template sentences may be created for various constructs inthe source code, such as software modules, function calls, functiondefinitions, and/or assignment statements. In these embodiments, thetemplate sentences may be filled in using, for example, variable namesand/or values recited in a given construct in the source code. Forexample, a template sentence for an assignment statement may be “Assign[INSERT VALUE] to [INSERT VARIABLE NAME].” In this example, the templatesentence may be applied to the assignment statement “result=0” to yieldthe completed sentence “Assign 0 to result.” In another example, atemplate sentence for a for loop statement may be “For every element in[INSERT LIST NAME] as [INSERT ELEMENT NAME] do the following.” In thisexample, the template sentence may be applied to the for loop statement“for number in list_of_numbers:” to yield the completed sentence “Forevery element in list_of_numbers as number do the following:”

For illustration, the steps of generating documentation for a computerprogram that triggers a software robot to: (1) start, (2) open a café,(3) make coffee in the café, (4) add sugar to the coffee, and (5) stopare shown in FIGS. 3-5. In particular, FIG. 3 shows an example AST forthe computer program, FIG. 4 shows an example SIT for the computerprogram, and FIG. 5 shows an example control flow graph for the computerprogram. The computer program contains three software modules: (1) aRobot Module, (2) a Shop Module, and (3) an Item Module. An exampleimplementation of the Robot Module in the Python programming language isshown below in Table 1:

TABLE 1 Example Code for Robot Module Line Number Code 1 from Shopimport Cafe 2 def run( ): 3 docstring (“* Start robot.”) 4 ccd = Cafe( )5 latte = ccd.make_coffee( ) 6 Cafe.add_sugar(latte) 7 docstring(“* Stoprobot.”)

As shown in Table 1, the Robot Module imports the class “cafe” from theShop Module in line 1, defines a function “run” in line 2, initializes anew cafe object called “ccd” in line 4, makes coffee called “latte” fromthe “ccd” café object in line 5, and adds sugar to the coffee named“latte” in line 6. FIG. 3 shows an AST 300 for the Robot Module inTable 1. The AST 300 comprises a plurality of nodes (shown as ovals)that represent a construct in the code (e.g., a software module, afunction call, a function definition, and/or an assignment statement)for the Robot Module that are interconnected by links (shown as arrows)that illustrate the relationships between constructs. As shown, the AST300 for the Robot Module does not include all of the constructs forclasses and/or functions defined outside the Robot Module, such as thoseclasses and/or functions defined in the Shop Module and the Item Module.Accordingly, an SIT may be created that illustrates the relationshipsbetween the ASTs to form a more complete representation of the sourcecode for the computer program.

An example implementation of the Shop Module in the Python programminglanguage is shown below in Table 2:

TABLE 2 Example Code for Shop Module Line Number Code  1 from Itemimport Coffee, Sugar:  2 class Cafe:  3 def _(——)init_(——) (self):  4docstring (“* Open cafe.”)  5 pass  6 def make_coffee(self) −> Coffee: 7 coffee = Coffee( )  8 return coffee  9 @staticmethod 10 defadd_sugar(c: Coffee) −> None: 11 docstring (“* Add sugar.”) 12c.ingredient = Sugar( )As shown in Table 2, the Shop Module imports the classes “Coffee” and“Sugar” from the Item module in line 1 and defines a class “Café” inlines 2-12 including the function “make_coffee” in lines 6-8 and thefunction “add_sugar” in lines 10-12.

An example implementation of the Item Module in the Python programminglanguage is shown below in Table 3:

TABLE 3 Example Code for Item Module Line Number Code 1 class Coffee: 2def _(——)init_(——)(self): 3 docstring (“* Make coffee.”) 4 pass 5 classSugar: 6 def _(——)init_(——)(self): 7 passAs shown in Table 3, the Item Module defines the class “Coffee” in lines1-4 and defines the class “Sugar” in lines 5-7.

As discussed above, the ASTs for the individual software modules may notrepresent relationships between the ASTs. Accordingly, an SIT may beformed that includes these relationships between ASTs. FIG. 4 shows anexample SIT 400 for the computer program that is generated using the AST300 for the Robot Module and ASTs for the Shop and Item Modules. The SIT400 comprises a plurality of nodes (shown as ovals) that represent aconstruct in the code (e.g., a software module, a function call, afunction definition, and/or an assignment statement) for the RobotModule that are interconnected by links (shown as arrows) thatillustrate the relationships between constructs. Return paths in the SIT400 are shown within square brackets and may be indicative of, forexample, the location where a construct associated with a given node isdefined. As shown, the nodes representing each of the “Coffee” and“Sugar” classes are children of both the Item Module and the Shop Modulebecause the Item Module defines these classes and the Shop Moduleimports these classes. Similarly, the node representing the “Cafe” classis a child of both the Shop Module and the Robot Module because the ShopModule defines the class and the Robot Module imports the class. As maybe appreciated from FIG. 4, the generated SIT 400 includes informationabout the class and scope of variables that is missing in the ASTs.

The SIT 400, along with the AST 300 for the Robot Module and/or ASTs forthe Shop and Item modules, may be employed to generate the control flowgraph 500 in FIG. 5 that is indicative of an execution flow of thecomputer program. As shown, the control flow graph 500 comprises aplurality of nodes each associated with a code portion from the sourcecode. The arrows between nodes in the control flow graph 500 may beindicative of an order of execution of the code portions associated withthe nodes.

The control flow graph 500 may be employed to create documentation forthe computer program. For example, documentation in natural languagetext may be generated for each node in the control flow graph 500.Thereby, the control flow graph 500 may serve as an index to organizepresentation of the documentation. The documentation may be generatedusing any of the techniques described herein. For example, thedocumentation may be extracted directly from comments (e.g., specialcomments) embedded in the code portions. Alternatively (oradditionally), the documentation may be generated automatically byanalyzing the code portions.

Returning to FIG. 1, the executable code 106 of the computer program maybe, for example, a collection of machine instructions that may beexecuted by a computer system to run the computer program. Theexecutable code 106 may be generated from the source code 104 using, forexample, a compiler and/or a linker.

In some embodiments, the executable code 106 may comprise one or moremachine instructions to capture and store data in the storage component118 during execution. Thereby, information gathered during runtime ofthe executable code may be made available to the LiveDoc system 100 forincorporation into the documentation presented in the GUI 122 via thestorage component 118. The executable code 106 may add a label to theinformation stored in the storage component 118 that provides anindication to the LiveDoc system 100 where and/or how the informationshould be incorporated into the GUI 122. For example, the executablecode 106 may comprise instructions to take a screenshot of a GUI of thecomputer program at particular points in the code and store the capturedscreenshots in the storage component 118 with a label. In this example,the LiveDoc system 100 may be configured to use the label to identifywhere the screenshot is to be incorporated into the documentation. Inanother example, the executable code 106 may comprise instructions tocount how many times particular code portions are executed and write thevalues for each code portion to a file with a label in the storagecomponent 118. In this example, the LiveDoc system 100 may use the labelto identify which code portion each of the values in the file correspondto and, thereby, how to employ the values in the GUI 118.

The configuration channel 116 may be configured to detect changes to oneor more GUI elements (e.g., configurable fields) in the GUI 122 and makecorresponding changes to the computer program (e.g., the source code 104and/or the executable code 106). Thereby, the configuration channel 116may function as a link between the GUI 122 and the source code 104and/or the executable code 106. The configuration channel 116 may createthis link using any of a variety of techniques. In some embodiments, aGUI element is incorporated into the GUI 122 that may be manipulated bythe user 120. The GUI element may be, for example, a drop-down list, aradio button, a toggle button, a checkbox, a text field, and a slider.The GUI element may be associated with parameter in the computer programthat may be altered. The configuration channel 116 may detect input bythe user 120 into the GUI element and, responsive to detecting the userinput, modify execution of the computer program.

In some embodiments, the configuration channel 116 may modify executionof the computer program without changing the source code 104. In theseembodiments, the computer program may read one or more files to identifysettings for parameters in the computer program. Thereby, theconfiguration channel 116 may modify execution of the computer programby modifying the files from which the computer program reads. Forexample, the computer program may read a table to identify values forone or more variables. In this example, the configuration channel 116may modify entries in the table to modify execution of the computerprogram.

In some embodiments, the configuration channel 116 may modify executionof the computer program by directly manipulating the source code 104. Inthese embodiments, the configuration channel 116 may modify one or morelines of code in the source code 104 to generate modified source code.The configuration channel 116 may, then, convert the modified sourcecode into modified executable code 106 (e.g., using a compiler and/or alinker). The configuration channel 116 may stop (or pause) execution ofthe executable code 106 and, in its place, execute the modifiedexecutable code.

Example Processes

As discussed above, the inventors have devised various techniques forcreating documentation for computer programs, such as software robotcomputer programs. An example process to create such documentation for acomputer program is shown in FIG. 6 by process 600. Process 600 may beperformed by, for example, a computer system such as computer system1100 described below. As shown, the process 600 includes an act 602 ofaccessing source code, an act 604 of analyzing the source code toidentify relationships between software modules, an act 606 of obtainingdocumentation using the identified relationships, and an act 608 ofoutputting generated documentation.

In act 602, the system may access source code associated with a computerprogram. The source code may be, for example, sub-divided into aplurality of software modules. Each of these software modules maycomprise, for example, instructions to perform one or more softwareroutines. The software modules may be stored together in a single fileor separated over a plurality of files on a non-transitory computerreadable medium. The system may access the source code by, for example,accessing (and/or retrieving) the software modules from one or morefiles.

In act 604, the system may analyze the source code to identifyrelationship(s) between the software modules in the source code. Thesystem may analyze the source code to identify relationships betweensoftware modules using any of a variety of techniques. In someembodiments, the system generates an AST for at least some of thesoftware modules and parses the generated ASTs to identify relationshipsbetween constructs in the ASTs. These relationships may be representedin, for example, an SIT.

In act 606, the system may obtain documentation using the identifiedrelationships. The system may obtain documentation by, for example,generating a control flow graph based on the identified relationshipsbetween software modules that is indicative of an execution flow of thecomputer program. The control flow graph may comprise, for example, aplurality of nodes each representative of a code portion (e.g., a codesnippet) from the source code and a plurality of links that connect thecode portions to show one or more execution paths. The control flowgraph may be employed to create an index for the software documentation.For example, the system may obtain software documentation for each nodeand organize the obtained documentation in the same fashion as thecontrol flow graph. The system may obtain the software documentation foreach node in any of a variety of ways. For example, the system maydirectly obtain the software documentation from comments (e.g., specialcomments) embedded in the code portion associated with the node. Inanother example, the system may generate the software documentation byconverting one or more lines of code in the code portion associated withthe node into natural language text.

It should be appreciated that the system may obtain softwaredocumentation for only a portion of the nodes in the control flow graph.In some embodiments, the system may generate a business flow graph thatonly comprises certain nodes from the control flow graph that have oneor more predetermined characteristics. Thereby, nodes that are specificto the particular implementation of a higher-level process in the sourcecode may be separated from nodes that are part of the high-levelprocess. For example, the business flow graph may only comprise nodesfrom the control flow graph that involve a particular set of variables.

In act 608, the system may output the generated documentation. Thesystem may output the generated documentation in any of a variety offormats. For example, the system may output the generated documentationas a text file and/or a webpage.

In some embodiments, the generated software documentation may bepresented to a user via a GUI. For example, a GUI may be presented to auser (e.g., via a web-browser) that illustrates at least part of thelogic implemented in the source code using, for example, graphics and/ornatural language text. Additionally (or alternatively), informationgathered during execution of the computer program, such as screenshots,may be incorporated into the GUI to further assist a user to understandthe computer program. An example process to generate a graphical userinterface (GUI) to display documentation for a computer program is shownin FIG. 7 by process 700. Process 700 may be performed by, for example,a computer system such as computer system 1100 described below. Asshown, the process 700 includes an act 702 of accessing source code, anact 704 of identifying an execution flow of the source code, an act 706of executing the computer program, an act 708 of obtaining informationgathered during execution of the computer program, and an act 710 ofgenerating a GUI.

In act 702, the system may access source code associated with a computerprogram. The source code may be, for example, sub-divided into aplurality of software modules. Each of these software modules maycomprise, for example, instructions to perform one or more softwareroutines. The software modules may be stored together in a single fileor separated over a plurality of files on a non-transitory computerreadable medium. The system may access the source code by, for example,accessing (and/or retrieving) the software modules from one or morefiles.

In act 704, the system may identify an execution flow of the sourcecode. The system may identify the execution flow of the source codeusing any of a variety of techniques described herein. For example, thesystem may identify the execution flow of the source code by generatinga control flow graph and/or a business flow graph of the source code.

In act 706, the system may execute the computer program. The system mayexecute the computer program by, for example, running the executablecode associated with the computer program. The executable codeassociated with the computer program may comprise, for example, one ormore instructions to output information during execution. For example,the executable code may comprise instructions to count a number of timesparticular code portions (e.g., code portions associated with nodes in acontrol flow graph or a business flow graph) are executed.

In act 708, the system may obtain information gathered during executionof the computer program. The system may obtain the information gatheredduring execution of the computer program by reading files stored in apre-determined location. For example, the system may read a filecomprising values indicative of how many times one or more code portionsof the source code have been executed.

In act 710, the system may generate a GUI using the identified executionflow and/or the obtained information. For example, a visualrepresentation of the execution flow may be shown in the GUI by aplurality of elements (e.g., nodes) that are each associated with a codeportion of the source code. These elements may be connected by linksthat illustrate how the code portions are traversed during execution. Inthis example, the GUI may transition from a first view showing a visualrepresentation of the execution flow to a second view that showssoftware documentation for a particular node responsive to selection ofa node. An example implementation of such a GUI is described in moredetail below with reference to FIGS. 9A-9B.

In some embodiments, the visual representation of the execution may begenerated based on the information obtained during execution of thecomputer program. In these embodiments, one or more characteristics(e.g., color, shape, and/or size) of one or more GUI elements in thevisual representation of the execution flow (e.g., nodes and/or links)may be changed based on the information obtained. For example, a size ofthe links between two nodes may be modified based on the number of timesthe computer program executed both code portions associated with thelink (e.g., the number of times the computer program traversed the linkduring execution).

In some embodiments, the generated documentation may permit a user tomanipulate one or more characteristics of how the computer programexecutes. For example, the generated documentation may be provided in aGUI to a user and include a GUI element (e.g., a configurable field)that may be changed by the user. In this example, a change to a value inthe GUI element may trigger a change to the underlying source code. Anexample process to configure execution of a computer program through aGUI is shown in FIG. 8 by process 800. Process 800 may be performed by,for example, a computer system such as computer system 1100 describedbelow. As shown, the process 800 includes an act 802 of accessing sourcecode, an act 804 of obtaining documentation using the source code, anact 806 of generating a GUI, an act 808 of receiving user input via theGUI, and an act 810 of modifying execution of the computer program basedon the user input.

In act 802, the system may access source code associated with a computerprogram. The source code may be, for example, sub-divided into aplurality of software modules. Each of these software modules maycomprise, for example, instructions to perform one or more softwareroutines. The software modules may be stored together in a single fileor separated over a plurality of files on a non-transitory computerreadable medium. The system may access the source code by, for example,accessing (and/or retrieving) the software modules from one or morefiles.

In act 804, the system may obtain documentation using the source code.The system may obtain documentation using any of a variety of techniquesdescribed herein. For example, the system may extract the softwaredocumentation directly from comments (e.g., special comments) in thesource code. In another example, the system may convert one or moreportions of the source code into natural language text.

In act 806, the system may generate a GUI that comprises the softwaredocumentation. In some embodiments, the GUI may comprise a GUI elementconfigured to receive user input (e.g., a configurable field) embeddedin the software documentation. The configurable field may be, forexample, a drop-down list, a radio button, a toggle button, a checkbox,a text field, and a slider. The GUI element may be associated with, forexample, a configurable parameter in the computer program such as avariable.

In act 808, the system may receive user input via the GUI. The userinput may comprise, for example, a change to the GUI element in the GUI.

In act 810, the system may modify execution of the computer programbased on the user input. The system may modify execution of the computerprogram in any of a variety of ways. In some embodiments, the system maymodify execution of the computer program by modifying a file that isread by the computer program during execution. For example, the computerprogram may read a table to identify values for one or more variables.In this example, the system may change the values for the one or morevariables in the table to modify execution of the computer program. Inother embodiments, the system may modify execution of the computerprogram by changing the source code for the computer program. Forexample, the system may change one or more lines of the source codeassociated with a parameter that was manipulated in the GUI. The systemmay use the modified source code to generate new executable code using,for example, a compiler and/or a linker. In another example, the systemmay generate modified source code by notifying (e.g., send an e-mail,adding a change code request to a queue, etc.) one or more human users(e.g., software engineers).

Various inventive concepts may be embodied as one or more processes, ofwhich examples have been provided. The acts performed as part of eachprocess may be ordered in any suitable way. Thus, embodiments may beconstructed in which acts are performed in an order different thanillustrated, which may include performing some acts simultaneously, eventhough shown as sequential acts in illustrative embodiments.

Example User Interfaces

As discussed above, the generated software documentation for a computerprogram may be provided to a user through a GUI. Further, the GUI may beconfigured to permit a user to change a value in one or moreconfigurable field to change execution of the source code. FIGS. 9A-9Bshow an example of such a GUI comprising a first view 900A and a secondview 900B to show the software documentation generated for a softwarerobot that is configured to control one or more other applications toprocess an insurance claim. As shown, the first view comprises abusiness flow graph 902 that illustrates the business logic implementedin the source code of the software robot through a plurality of nodes904. The business logic implemented in the particular software robotcomprises the following nodes 904: (1) receive insurance claim; (2) noevidence provided to establish a loss; (3) evidence provided establish aloss; (4) insurance claim value is less than $10 million; (5) insuranceclaim is not covered by the insurance policy; (6) insurance claim iscovered by insurance policy; (7) insurance claim value exceeds $10million; (8) insurance claim is not covered by insurance policy; (9)insurance claim is covered by insurance policy. The nodes 904 may bedepicted in the first view 900A as, for example, a particular symbol(e.g., a circle, a square, a rectangle, and/or a star). The nodes 904are interconnected by links 906 to show how the computer programtraverses the various nodes in the business flow graph 902.

The depiction of the nodes 904 and/or the links 906 in the business flowgraph 902 may change in accordance with one or more characteristics ofexecution of the computer program. For example, the size, color, and/orshape of the nodes 904 and/or links 906 may be changed. In someembodiments, the size of the links 906 may be proportional to a numberof times the particular link is traversed by the computer program. Inthis example, links 906 between nodes 904 that are commonly traversedmay be larger (e.g., wider) than other links 906 in the business flowgraph. Additionally (and/or alternatively), a color of a given node 906may change based on a number of times the computer program successfullyexecutes one or more lines of code associated with the respective node.This information may be captured by, for example, inserting instructionsinto the computer program to count how many times code portionsassociated with each of the nodes 904 are executed (and/or executedsuccessfully) and store these values in a file. Thereby, these valuesmay be subsequently read and employed to modify one or morecharacteristics of the business flow graph 902.

The first view 900A may include additional information separate andapart from the business flow graph 902. For example, the first view 900Amay also include a chat box 908 that is configured to receive messages(e.g., questions) from a user in a message field 912 and provideautomated responses to the received messages in the response field 914.The chat box 908 may be configured to respond to, for example, a set ofone or more pre-determined questions relating to one or more nodes 904and/or links 906 in the business flow graph 902 such as “How many timeshas the Claim exceeds $10 million node has been reached duringexecution?”

In some embodiments, the GUI shown in FIGS. 9A and 9B may transitionfrom the first view 900A to the second view 900B responsive to selectionof a node 906 in the business flow graph 902. The second view 900B mayinclude, for example, software documentation in natural language textfor a code portion associated with the selected node. For example,documentation associated with the node “(4) for claims less than $10million” may be shown responsive to selection (e.g., selection by auser) of the respective node. As shown in FIG. 9B, the second viewcomprises documentation 916 regarding the code portion associated withthe selected node. The documentation 916 may comprise, for example,natural language text regarding the logic implemented in the associatedcode portion from the source code. The second view 900B furthercomprises a configurable field 918 in the documentation 916. Theconfigurable field 918 may be, for example, a field comprising a valuethat may be configured by a user to modify execution of the computerprogram. The configurable field 918 may be implemented in any of avariety of ways such as: a drop-down list, a radio button, a togglebutton, a checkbox, a text field, and a slider. The second view furthercomprises an inspect code button 920 that, upon activation, triggers theGUI to display the code portion associated with the selected node (e.g.,via an integrated development environment (IDE)), an edit lock button922 that, upon activation, triggers the GUI to lock the configurablefield 918, and a submit button 924 that, upon activation, that modifiesexecution of the computer program using the value in the configurablefield 918.

FIGS. 10A-10C illustrate another example of a GUI configured to displaysoftware documentation for a computer program. As shown, the GUIcomprises a first view 1000A, a second view 1000B, and a third view1000C that show documentation for a software robot computer programconfigured to process POs. Each of the views 1000A-C comprises an index1002 that is configured to permit a user to navigate between varioussections of the documentation. The index 1002 may comprises a pluralityof links to different portions of the documentation. For example, theGUI may transition to section 2 “Create a PO queue” of the softwaredocumentation upon selection of the “Create a PO queue” link in theindex 1002. The first view 1000A shows an example view for the “Readincome POs” section with documentation 1004 that comprises naturallanguage test. The second view 1000B shows an example view for the“Upload plan to seller central” section that comprises a screenshot 1006of a user interface shown by the computer program during execution of acode portion associated with this section. The third view 1000C shows anexample view for the “Get PO from the Queue” section that comprises aconfigurable field 1008 that permits a user (e.g., a non-technicalindividual) to easily change the fulfillment center (e.g., betweenMumbai, Bangalore, and Delhi) used by the computer program in obtaininga PO from a queue.

Example Computer System

An illustrative implementation of a computer system 1100 that may beused in connection with any of the embodiments of the disclosureprovided herein is shown in FIG. 11. For example, the LiveDoc system 100may be implemented on and/or using computer system 1100. The computersystem 1100 may include one or more processors 1110 and one or morearticles of manufacture that comprise non-transitory computer-readablestorage media (e.g., memory 1120 and one or more non-volatile storagemedia 1130). The processor 1110 may control writing data to and readingdata from the memory 1120 and the non-volatile storage device 1130 inany suitable manner, as the aspects of the disclosure provided hereinare not limited in this respect. To perform any of the functionalitydescribed herein, the processor 1110 may execute one or moreprocessor-executable instructions stored in one or more non-transitorycomputer-readable storage media (e.g., the memory 1120), which may serveas non-transitory computer-readable storage media storingprocessor-executable instructions for execution by the processor 1110.

The terms “program” or “software” are used herein in a generic sense torefer to any type of computer code or set of processor-executableinstructions that can be employed to program a computer or otherprocessor to implement various aspects of embodiments as discussedabove. Additionally, it should be appreciated that according to oneaspect, one or more computer programs that when executed perform methodsof the disclosure provided herein need not reside on a single computeror processor, but may be distributed in a modular fashion amongdifferent computers or processors to implement various aspects of thedisclosure provided herein.

Processor-executable instructions may be in many forms, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically, the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

Also, data structures may be stored in one or more non-transitorycomputer-readable storage media in any suitable form. For simplicity ofillustration, data structures may be shown to have fields that arerelated through location in the data structure. Such relationships maylikewise be achieved by assigning storage for the fields with locationsin a non-transitory computer-readable medium that convey relationshipbetween the fields. However, any suitable mechanism may be used toestablish relationships among information in fields of a data structure,including through the use of pointers, tags or other mechanisms thatestablish relationships among data elements.

Also, various inventive concepts may be embodied as one or moreprocesses, of which examples have been provided. The acts performed aspart of each process may be ordered in any suitable way. Accordingly,embodiments may be constructed in which acts are performed in an orderdifferent than illustrated, which may include performing some actssimultaneously, even though shown as sequential acts in illustrativeembodiments.

All definitions, as defined and used herein, should be understood tocontrol over dictionary definitions, and/or ordinary meanings of thedefined terms.

As used herein in the specification and in the claims, the phrase “atleast one,” in reference to a list of one or more elements, should beunderstood to mean at least one element selected from any one or more ofthe elements in the list of elements, but not necessarily including atleast one of each and every element specifically listed within the listof elements and not excluding any combinations of elements in the listof elements. This definition also allows that elements may optionally bepresent other than the elements specifically identified within the listof elements to which the phrase “at least one” refers, whether relatedor unrelated to those elements specifically identified. Thus, as anon-limiting example, “at least one of A and B” (or, equivalently, “atleast one of A or B,” or, equivalently “at least one of A and/or B”) canrefer, in one embodiment, to at least one, optionally including morethan one, A, with no B present (and optionally including elements otherthan B); in another embodiment, to at least one, optionally includingmore than one, B, with no A present (and optionally including elementsother than A); in yet another embodiment, to at least one, optionallyincluding more than one, A, and at least one, optionally including morethan one, B (and optionally including other elements); etc.

The phrase “and/or,” as used herein in the specification and in theclaims, should be understood to mean “either or both” of the elements soconjoined, i.e., elements that are conjunctively present in some casesand disjunctively present in other cases. Multiple elements listed with“and/or” should be construed in the same fashion, i.e., “one or more” ofthe elements so conjoined. Other elements may optionally be presentother than the elements specifically identified by the “and/or” clause,whether related or unrelated to those elements specifically identified.Thus, as a non-limiting example, a reference to “A and/or B”, when usedin conjunction with open-ended language such as “comprising” can refer,in one embodiment, to A only (optionally including elements other thanB); in another embodiment, to B only (optionally including elementsother than A); in yet another embodiment, to both A and B (optionallyincluding other elements); etc.

Use of ordinal terms such as “first,” “second,” “third,” etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed. Such terms areused merely as labels to distinguish one claim element having a certainname from another element having a same name (but for use of the ordinalterm).

The phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” “having,” “containing”, “involving”, andvariations thereof, is meant to encompass the items listed thereafterand additional items.

Having described several embodiments of the techniques described hereinin detail, various modifications, and improvements will readily occur tothose skilled in the art. Such modifications and improvements areintended to be within the spirit and scope of the disclosure.Accordingly, the foregoing description is by way of example only, and isnot intended as limiting. The techniques are limited only as defined bythe following claims and the equivalents thereto.

What is claimed is:
 1. A system, comprising: at least one hardwareprocessor; and at least one non-transitory computer-readable storagemedium storing processor-executable instructions that, when executed bythe at least one hardware processor, cause the at least one hardwareprocessor to perform: accessing source code of a computer program;generating a graphical user interface (GUI) including: documentation forthe computer program; and at least one GUI element for receiving userinput for modifying execution of the computer program; receiving userinput via the at least one GUI element; and modifying execution of thecomputer program based on the user input provided through the at leastone GUI element.
 2. The system of claim 1, wherein modifying executionof the computer program comprises setting at least one value of at leastone parameter of the computer program based on the user input providedthrough the at least one GUI element.
 3. The system of claim 1, whereinmodifying execution of the computer program comprises identifying, basedon the user input provided through the at least one GUI element, one ormore portions of the source code to not execute during execution of thecomputer program.
 4. The system of claim 3, wherein theprocessor-executable instructions further cause the at least oneprocessor to perform: modifying presentation of the documentation in theGUI based on the user input provided through the at least one GUIelement.
 5. The system of claim 4, wherein modifying presentation of thedocumentation in the GUI comprises visually highlighting a portion ofthe documentation affected by the modification.
 6. The system of claim1, wherein modifying execution of the computer program comprisesgenerating modified source code for the computer program using thesource code and the user input.
 7. The system of claim 6, whereinmodifying execution of the computer program comprises generating amodified executable code based on the modified source code and executingthe modified executable code.
 8. The system of claim 1, wherein thecomputer program is configured to read at least one value from a fileduring execution and wherein modifying execution of the computer programcomprises changing the at least one value in the file.
 9. The system ofclaim 1, wherein the at least one GUI element comprises at least oneelement selected from the group consisting of: a drop-down list, a radiobutton, a toggle button, a checkbox, a text field, and a slider.
 10. Thesystem of claim 1, wherein the processor-executable instructions furthercause the at least one processor to perform: generating informationindicative of execution flow of the computer program at least in part byanalyzing the source code; and obtaining the documentation using theinformation indicative of execution flow of the computer program. 11.The system of claim 10, wherein generating the GUI comprises: generatinga visualization of the execution flow of the computer program thatcomprises a plurality of GUI elements each associated with acorresponding code portion in the source code of the computer program.12. The system of claim 1, wherein the processor-executable instructionsfurther cause the at least one processor to perform: generating initialdocumentation for the computer program at least in part by analyzing thesource code of the computer program; obtaining information gatheredduring execution of the computer program; and updating the initialdocumentation by using the information gathered during execution of thecomputer program to obtain the documentation to include in the GUI. 13.The system of claim 12, wherein analyzing the source code of thecomputer program comprises generating at least one abstract syntax tree(AST) for the source code.
 14. The system of claim 13, wherein thesource code of the computer program comprises a plurality of softwaremodules, and wherein generating the at least one AST for the source codecomprises generating an AST for each of the plurality of softwaremodules.
 15. The system of claim 1, wherein the computer program isconfigured to control another computer program to perform a task. 16.The system of claim 15, wherein the computer program is configured tocontrol the other computer program to perform the task at least in partby controlling a graphical user interface (GUI) of the other computerprogram to perform an action in furtherance of the task.
 17. A method,comprising: using at least one hardware processor to perform: accessingsource code of a computer program; generating a graphical user interface(GUI) including: documentation for the computer program; and at leastone GUI element for receiving user input for modifying execution of thecomputer program; receiving user input via the at least one GUI element;and modifying execution of the computer program based on the user inputprovided through the at least one GUI element.
 18. The method of claim17, wherein modifying execution of the computer program comprisessetting at least one value of at least one parameter of the computerprogram based on the user input provided through the at least one GUIelement.
 19. The method of claim 17, wherein modifying execution of thecomputer program comprises identifying, based on the user input providedthrough the at least one GUI element, one or more portions of the sourcecode to not execute during execution of the computer program. 20-32.(canceled)
 33. At least one non-transitory computer-readable storagemedium storing processor-executable instructions that, when executed byat least one hardware processor, cause the at least one hardwareprocessor to perform: accessing source code of a computer program;generating a graphical user interface (GUI) including: documentation forthe computer program; and at least one GUI element for receiving userinput for modifying execution of the computer program; receiving userinput via the at least one GUI element; and modifying execution of thecomputer program based on the user input provided through the at leastone GUI element.